其他
质量很难，测试不易，且行且珍惜
质量是价值的体现、是公司的生存之道。 软件质量是企业生命线、产品的生命线。持续优化、持续改进。 软件质量管理是一个长期进化的历程，没有止境唯有更好，企业能走多远质量管理就有多严。 质量是一个系统工程，短时间很难看到成效，持续改进是最好的方法。 团队时刻关注质量，质量是团队中每个成员头上悬着的一把刀，持续改进深深烙在每个人心中。 没有质量保证的高速开发是一种灾难。 质量是1到100的事情。 质量免费，第一次做对成本最低。 质量不是某个人的事、某个版本的事，而是一种习惯的养成。 坚持以客户为中心，站在客户角度考虑问题。 站在最终用户/客户的角度才能衡量一个产品的质量。 检验质量的主要标准只有一个：满足使用者的实际需要，用户使用软件获得了预期的信息化带来红利。 如果质量不重要，那么在做的事情一定是不重要的。 你永远都不知道你的用户会怎样使用你的产品。 业务发展走在前面，组织架构变革要紧随其后，质量文化要根植于心。 质量是内建的，质量不是测出来的，但很多开发人员意识不够。 质量是集体内建的，缺陷的预防重于缺陷发现，这个文化还没有形成。 所有与质量有关的人都必须要有对质量的责任心，这样流程才有人遵循，规范才有人落实，质量才有人保证。 软件质量根源是开发质量，测试如何帮助提升开发质量是一个视角。 质量是一种文化，这点很重要，需要每个岗位上的人员共同加入并与自身工作融入。 流程和标准背后是企业文化，文化畸形结果自然不好。 提高质量意识，流程控制质量，避免个人能力差异。 质量不是口号，需要实质性行动。 质量文化的建设，不能只靠理论宣传，更依赖实际有效的行动，以及过程的持续把控和改进。 质量很重要，做好质量很难，需要有强领军人物和把质量重要性落到实处，而不仅仅是一句口号。 关于软件质量，始终坚持：软件质量不是测试出来的，需要对整个软件项目的整个流程进行构建，以及质量保障体系的建立。构建质量体系才是提升软件质量的核心部分。 软件质量的提升应该是全面质量管理、全员参与意识以及持续不断的价值交付效率的提升，以内部流程达到CMMI3的流程规范以及质量达到3西格玛作为年度质量目标 质量无穷尽，关注质量的同时也要关注如何低成本的实现高质量。 研发前中后三个阶段都需强调质量的重要性，软件质量是要靠全流程来保障，但现实中，不同角色对质量认知标准不一致，需要改变。 软件质量受软件生命周期中的每个细节影响，要想做好软件质量保障，必须全方位监控。 需要对软件过程有敬畏之心。 流程与人员，对质量缺一不可。 软件工程中人是万恶之源，培养人的能力与责任感，人人对自己的事负责，质量会有提升。 无论规范是否建立，软件质量还是和个人能力关系较大。 完善基础设施的情况下，以人为本，事半功倍。 流程规范严谨，开发前做好各种评估工作。 开发流程管控对质量的影响比具体细节更重要。 提倡全过程、关键环节全流程质量管理。质量管理是全员扎实做出来的，不是某方面管出来的。 还是得自上而下的支持、优化流程，提高各类人员的专业素质。 质量必须是一把手工程。一把手不把质量放在经营同等重要位置，没有办法从根本上提升软件质量。 质量问题归根结底是管理问题。 领导重视是关键，部门领导不重视质量，有再多的规范流程，也很难落地执行。 软件质量任重道远，需要领导重视、项目支持。 全员、全面、全流程、全天候质量，各个环节都要问责！ 质量来源于团队整体的保证，需强调团队责任。 质量面前人人有责，质量是全公司至上而下所有人的努力的结果。 看软件的质量就先看生产它的组织，如果组织混乱，分工不清，质量肯定不行。 质量不单单是测试的事情，全员都需要有质量意识。 软件质量根本是研发质量，就像空气污染的源头是排放污染的企业，而不是监管部门。 软件质量不仅仅是测试人员的责任，应该是全员责任，这应该成为一种共识。 提测质量上不去，质量给进度让步，凡事给业务方跪舔，本身就说明了团队导向有问题。 除了建立各种规范，还得有度量，没有度量就没有改进，但也不能一味地依赖度量，可以当做一种改进的途径。 质量从需求开始，靠开发规范，测试人员保障。 需要从细节入手，不急功近利，急于求成。 开发写每一行代码都要考虑质量，提倡开发测试一体化。 质量需要有可靠的工具和有效的方法、加强规范流程来保证。 持续性的迭代质量需要一个规范的流程来保障，需要团队成员包含领导层有共同的质量意识。 软件质量是设计出来的不是测出来的，不能把所有的问题都遗留给功能测试团队去解决。 软件设计模式的选取很重要，选对了，可以节省很多时间；产品设计定位不好，累死开发、测试、交付人员。 质量由测试说了算，拍胸脯、做保证都是扯淡，见过最多的就是项目之初胸脯拍得响，后期掉链子，质量不是主观上的自信能得到的。 测试背锅的角色始终没有改变，很多行业对测试作用的理解存在误区。 测试人员可尽早介入开发设计的评审，了解设计思路，结合功能业务和设计分析会更加有针对性。 测试一定要左移，整个团队的质量意识要提高，提测后为时已晚。 面对的系统本身的特性，个性化的保证不同的方面，也是质量保证的关键。 质量意识是前提，测试基建是基础。准入准出靠测试标准，问题挖掘靠大脑。 专业的人做专业的事，不懂软件的人不要硬套方法论。 感觉公司的软件质量需要改进的地方很多，但是没有找到真正适合自己的路。 质量是构建出来的，通过人的创造力和科学的技术运用，找到适合适用自身的。 对于软件质量的评判标准还是要有一个可视化的标准。 软件质量不是测出来的，应该从源头设计开始，全员参与测试！ 软件质量与开发密切相关。懂开发才更懂测试，开发和测试要共担质量。 保证软件质量是测试人员的基本素养。 通过持续测试来提升软件质量。 提升测试人员的能力，希望团队领导能更加重视和投入很多的精力在测试和质量保证这块。 渔网的好坏和池塘里有没有鱼是没有关系的，测试设计的好坏和系统中有没有bug也是没有关系的。 在低成熟度的企业里，百人规模以上应该更强调传统的QA职能，强调过程裁剪和规范。小规模和成熟度高的企业可弱化QA职能。 聚集核心业务价值，质量与效率相平衡。 软件质量是重中之重，质量就是效率。 AI未来将会起到很大作用。 在智能AI评估器到来前，这所有的一切都是人为的构建、构建、构建！只能证明哪些地方无恙，不能说明一切安好。 增强自动化客观指标体系建设。 质量在于团队协同，协同不好，再牛的人产出也低。 关于软件质量，它是一个让人头疼又非常有趣的谈之不尽的话题。 很多时候感觉自己很容易到了天花板，心力交瘁，无法入手，领导想重视但是没给力支持。 国内互联网企业竞争激烈，研发团队基本都是在做功能实现的事情，中间过程没有质量保障的活动，比如设计和代码评审、单元测试等这些最基础的质量保障活动，牺牲这些时间来追赶进度，尽快占领市场。大家都知道这是饮鸩止渴，但项目太多、老板不断施压，很难找到走出这个困局的办法。 单元测试怎么落地，难啊！！ 要质量没速度，要速度没质量。 软件最终是交付给客户的，没有用户量没有兑「现」，都是无法体现软件质量的。 因压缩资源成本，砍掉很多测试的工时，很难过。 对于重灾区的团队，吹哨人会被干掉。 公司不注重质量，只求快速出成品，测试孤独寂寞冷。 企业高层对质量认识不足、理解有偏差，业界又缺乏质量实践经验分享和支撑，质量工作很难开展。 现在产品越来越追求快，质量技能却未跟进，测试很被动，干的越来越辛苦。 敏捷开发，基础设施和服务要扎实，否则跑着跑着轮子都掉了，就别提敏捷了。 感觉好难推动各个阶段的质量把控，好多环节如需求评审，形式大于效果。 软件质量都认为重要，但在进度等压力下又容易会被忽视，人们更容易关注带来短期效益的直接指标而对改进质量带来的、缓慢的长期收益视而不见。 软件质量靠的还是整体的构建，单靠其中任何一个环节都是不行的。吐槽的地方很多，越来越快的迭代频率，越来越短的开发周期，总有更高优先级的需求插队。 体制内单位的组织改进，需要自上而下，全方位的去改。因为企业文化的原因，导致任何改变都无比艰难，牵一发而动全身。 当前规范太杂乱，国标又很多不适用，要是有专业机构来牵头规范会好点。 质量很难，测试不易，且行且珍惜。